SYSTEM AND METHOD FOR PROVIDING AUTHORIZATION AND OTHER 
SERVICES 



This patent application claims priority from U.S. provisional application serial No. 
60/231,313, filed September 8, 2000, entitled Authorization/Credential Service and 
Authorization/Credential Service Proposal; U.S. provisional application serial No. 
60/231,315, filed September 8, 2000, entitled Authorization/Credential Service Proposal; 
and U.S. provisional application serial No. 60/231,318, filed September 8, 2000, entitled 
Authorization/Credential Service, which are hereby incorporated by reference. 

BACKGROUND OF THE INVENTION 

The world of electronic commerce has created new challenges to establishing 
relationships between contracting parties. One of those challenges springs from the fact that 
the parties to the transaction cannot see or hear each other, and cannot otherwise easily 
confirm each other's identity and authority to act. 

One remedy for this problem is to provide each confracting party with a private key 
for signing transmitted messages. The signing party makes available an associated public 
key that decrypts messages signed with the party's private key, and thus enables a receiving 
party to confirm the identity of the sender. 

But the sender's public key may not be known a priori to the recipient. In that 
event, the sender may transmit with its signed message a digital certificate issued by a 
certification authority. The certificate is itself a signed electronic document (signed with the 
private key of the certification authority) certifying that a particular public key is the public 
key of the sender. 

In some cases, the recipient may be unfamiliar with the pubhc key of the 
certification authority or may not know whether the certificate is still valid. In that event, 
the recipient may wish to check the vahdity of the certificate. In addition, the recipient may 
wish to check whether or not the sender is authorized to sign the fransmitted message. 

SUMMARY OF THE INVENTION 

A system and method are disclosed for providing authorization and other services. 
In a preferred embodiment, these services are provided within the context of a four-comer 
trust model. The four-comer model preferably comprises a subscribing customer 
(sometimes referred to as the "buyer") and a relying customer (sometimes referred to as the 
"seller"), who engage in an on-line fransaction. 
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In a preferred embodiment, the subscribing customer is a customer of a first 
financial institution, referred to as an issuing participant. The issuing participant acts as a 
certification authority for the subscribing customer and issues the subscribing customer a 
hardware token including a private key and a digital certificate signed by the issuing 
5 participant. 

Li a preferred embodiment, the relying customer is a customer of a second financial 
institution, referred to as the relying participant. The relying participant acts as a 
certification authority for the relying customer and issues the relying customer a hardware 
token including a private key and a digital certificate signed by the relying participant. The 
1 0 system also includes a root entity that maintains a root certification authority that issues 
digital certificates to the issuing and relying participants. 

The present system provides a generalized firamework for designing and 
implementing one or more authorization services that maybe used to confirm the authority 
of an individual to act on behalf of a customer. Such authorization services may be used, 
1 5 for example, to determine whether a particular employee is authorized to purchase certain 
goods, negotiate a particular contract, or undertake to perform in a particular manner on 
behalf of its employer. 

In a preferred embodiment, authorization services in the present system maybe 
designed and implemented in accordance with the following process. First, a customer and 
20 its participant work together to define a desired authorization service. The authorization- 
service definition preferably includes both a messaging specification for the service and a 
set of rules that govern its use, as described in more detail below. 

Second, the proposed authorization service is presented to a policy management 
authority maintained by the root entity for approval. The pohcy management authority 
^5 reviews the proposed authorization service for compliance with system operating rules and 
specifications promulgated by the root entity. 

Third, if the proposed authorization service is approved by the root-entity pohcy 
management authority, the service is implemented within the four-comer model. 

When a relying customer wishes to utilize an approved authorization service, it 
►0 prepares an authorization request that complies with the service's messaging specification 
and transmits the request to its relying participant. 

The relying participant transmits the request to the issuing participant which 
processes the request in accordance with authorization information provided by the 
subscribing customer as well as any implementation rules that have been specified for the 
5 service. The issuing participant then prepares an authorization response that complies with 
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the service's messaging specification and transmits the response to the relying participant. 
The relying participant transmits the authorization response to its relying customer. 

The features and advantages described in the specification are not all inclusive, and 
many additional features and advantages will be apparent to one of ordinary skill in the art 
5 in view of the drawings, specification, and claims hereof 

BRIEF DESCRIPTION OF THE DRAWINGS 

The above summary of the invention will be better understood when taken in 
conjunction with the following detailed description and accompanying drawings, in which: 

FIG. 1 is a block diagram of a preferred embodiment of a foiu--comer model suitable 
for use in the present system; 

FIG. 2 is a block diagram of a preferred embodiment showing components provided 
at entities in the present system; 

FIG. 3 illustrates a preferred embodiment for establishing an authorization service; 
FIG. 4 illustrates a preferred embodiment of a process flow for using an 
authorization service; 

FIG. 5 illustrates a preferred embodiment of certain messages transmitted in the 
preferred embodiment of FIG. 4. 

FIG. 6 illustrates a preferred embodiment of a process flow in which an 
authorization service and a certificate validation service are bimdled together; and 

FIG. 7 illustrates a preferred embodiment of certain messages transmitted in the 
preferred embodiment of FIG. 6. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The present disclosure relates to a system and method for providing authorization 
and other services. In a preferred embodiment, these services are provided within the 
context of a four-comer trust model. A preferred embodiment of a four-comer model 
suitable for use in the present system is shovm in FIG. 1 . 

As shown in FIG. 1, the four-comer model preferably comprises a first institution 
30 102 and a second institution 104. First institution 102 is referred to as the "issuing 
participant" because it is a participant in the present system and issues to its customers 
tokens that include a private key and a digital certificate signed by the issuing participant, as 
described below. Second institution 104 is referred to as the "relying participant" because it 
is a participant in the present system and its customers rely on representations made by 

35 
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issuing participant 102 and issuing participant 102's customers, as described below. 
Participants 102, 104 may preferably be banks or other financial institutions. 

Also shown in FIG. 1 are a first customer 106 and a second customer 108. First 
customer 106 and second customer 108 are preferably customers of issuing participant 102 
and relying participant 104, respectively. First customer 106 is referred to as the 
"subscribing customer" because this customer subscribes to services provided by issuing 
participant 102. First customer 106 is also sometimes referred to as the "buyer" because it 
typically fills that role in transactions with second customer 108, as described below. 

Second customer 108 is referred to as the "relying customer" because it rehes on 
representations made by both issuing participant 102 and subscribing customer 106. Second 
customer 108 is also sometimes referred to as the "seller" because it typically fills that role 
in transactions with first customer 106, as described below. It should be recognized, 
however, that although the description below speaks primarily in terms of a buyer 106 and a 
seller 108, first customer 106 and second customer 108 may instead have different roles in a 
given transaction. For example, first customer 106 may be a borrower repaying a loan to 
second customer 108. 

As will be recognized, although the preferred embodiments described below speak 
primarily in terms of customer 106 acting as a subscribing customer and customer 108 
acting as a relying customer, the roles of these two customers may at times be reversed, 
even within a single transaction and with respect to a single document. For example, in 
connection with a particular ti-ansaction, customers 106, 108 may prepare a contract to be 
signed by both parties. With respect to customer 106's signature on the contract, customer 
106 is the subscribing customer and customer 108 is the relying customer. By contrast, with 
respect to customer 108's signature on the contract, customer 108 is the subscribing 
customer and customer 106 is the relying customer. 

It should also be noted that each customer 106, 108, maybe a business entity, such 
as a corporation, that employs many individuals. In such cases, customers 106, 108 
preferably authorize some or all of these individual employees to transact and utihze system 
services on their behalf Issuing participant 102 preferably issues a separate smartcard 
token having a distinct private key and associated digital certificate to each authorized 
employee of subscribing customer 106. Similarly, relying participant 104 (in its capacity as 
"issuing participant" to relying customer 108) preferably issues a separate smartcard token 
having a distinct private key and associated digital certificate to each authorized employee 
of relying customer 108. The digital certificates preferably include the individual 
employee's name and identify the customer for whom he or she works. In an alternative 
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embodiment, the private key may instead be included in a software token provided to the 
individual. 

It should be recognized that although the description that follows may speak in terms 
of messages or other data being signed by a "subscribing customer" or "relying customer," 
the signature may in fact typically be created by an individual employee using his or her 
digital certificate and associated private key acting on behalf of his or her employer. 

Also shown in FIG. 1 is a root entity 110. Root entity 1 10 is preferably an 
organization that establishes and enforces a common set of operating rules for facilitating 
electronic commerce and electronic communications. Root entity 110 may be owned jointly 
by a plurality of banks and/or other financial institutions that have agreed to adhere to these 
operating rules. One exemplary embodiment of such a root entity is described in copending 
U.S. application serial No. 09/502,450, filed February 11, 2000, entitled System and 
Method for Providing Certification Related and Other Services and in copending U.S. 
apphcation serial No. 09/657,623, filed September 8, 2000, entitled System and Method for 
Providing Certificate-Related and Other Services, which are hereby incorporated by 
reference. 

FIG. 2 is a block diagram of a preferred embodiment showing components provided 
at each entity in the present system. As shown in FIG. 2, participants 102, 104, and root 
entity 1 10 are each preferably provided with a transaction coordinator 202 that serves as a 
gateway for transmitting and receiving all inter-entity messages related to services provided 
by the present system. Transaction coordinators 202 provide a single interface to issuing 
participant 102's and relying participant 104's on-line services and implement safeguards 
necessary to ensure secure electronic communications between transaction coordinators 202 
and other entities in the four-comer model, as described in copending U.S. application serial 
No. 09/657,605, filed on September 8, 2000, entitled System and Method for Providing 
Certificate Validation and Other Services, which is hereby incorporated by reference. Each 
transaction coordinator 202 is preferably provided with an associated hardware security 
module (HSM) 218 for signing and verifying messages. Participants 102, 104, and root 
entity 1 10 are each further preferably provided with an OCSP responder 204 and associated 
hardware security module (HSM) 206 for signing and verifying signatures on messages. 

Root entity 1 1 0 is also preferably provided with a central repository 260. Central 
repository 260 is preferably adapted to store data, such as, for example, messaging 
specification and other data as described in more detail below. 
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Participants 102 and 104 are each preferably provided with a directory 270. 
Directory 270 is preferably adapted to store data, such as, for example, credential records 
and messaging specification data, as described in more detail below. 

Subscribing customer 106 is preferably provided with a Web browser 224 adapted to 
receive and transmit information via the Intemet. Subscribing customer 106 is also 
preferably provided with a smartcard subsystem 226 adapted to sign electronic messages. In 
a preferred embodiment, smartcard subsystem 226 may include a smartcard reader, a 
smartcard driver, a smartcard token, and other software, as described in U.S. provisional 
application serial No. 60/224,994, filed August 14, 2000, entitled Signing Interface 
Requirements, Smart Card CompUance Requirements, Warranty Service Functional 
Requirements, and Additional Disclosure and copending U.S. application serial No. 
09/928,999, filed August 14, 2001, entitled System and Method for Secure Smartcard 
Issuance, which are hereby incorporated by reference. In a preferred embodiment, the 
smartcard token is issued to subscribing customer 106 by its issuing participant 102. 

Subscribing customer 106 is also preferably provided with a signing interface 225. 
Signing interface 225 is adapted to invoke smartcard 226 to execute a digital signature, as 
described in U.S. provisional appHcation serial No. 60/224,994, filed August 14, 2000, 
entitled Signing Interface Requirements, Smart Card Compliance Requirements, Warranty 
Service Functional Requirements, and Additional Disclosure and U.S. application serial No. 
09/929,035, filed August 14, 2001 , entitled System and Method for Facilitating Signing by 
Buyers in Electronic Commerce, which are hereby incorporated by reference. 

Relying customer 108 is preferably provided with a Web server 220 adapted to 
receive and ti-ansmit information via the Intemet and a bank interface 222 for accessing 
system services. An exemplary bank interface is described in copending U.S. application 
serial No. 09/657,604, filed on September 8, 2000, entitled System and Method for 
Facilitating Access by Sellers to Certificate-Related and Other Services, which is hereby 
incorporated by reference. Relying customer 108 is preferably fiirther provided with an 
HSM 250 for signing and verifying signatures on messages. 

Customers 106, 108 are also each preferably provided with a directory 280 that is 
adapted to store data, such as, for example, credential records and messaging specification 
data, as described in more detail below. 

In a preferred embodiment, each system entity is fiirther preferably provided with 
two digital certificates (and corresponding private keys) to facihtate authentication: an 
identity certificate and a utility certificate. 
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The identity private key is used to produce digital signatures that are required by 
root entity 110 as evidence of an entity's contractual commitment to the contents of an 
electronic transaction, such as a purchase order. 

The utihty private key is used to provide additional transactional security. Typically, 
5 utihty certificates are used to support secure socket layers (SSL), to sign secure 

multipurpose internet mail extension (S/MIME) messages, and for other utility appHcations. 
Any reference in this document to the term "certificate" refers to an identity certificate 
unless otherwise stated. 

In a preferred embodiment, root entity 1 10, in its capacity as a certification authority, 
1 0 uses a root private key to create the digital certificates of each system participant (e.g., 
issuing participant 102 and relying participant 104). hi addition, it uses the root private key 
to create digital certificates for each system component maintained by root entity 1 10 that 
has digital signing capability, including OCSP responder 204^ and transaction coordinator 
202^. 

In addition, each system participant (e.g., issuing participant 102 and relying 
participant 104), in its capacity as a certification authority, uses the private key associated 
with its ceri;ificate fi-om root entity 1 10 to create the digital certificates of its customers (e.g., 
subscribing customer 106 and relying customer 108). In addition, it uses this private key to 
create digital certificates for each system component that it maintains that has digital 
20 signing capability, including its OCSP responder 204 and transaction coordinator 202. hi an 
alternative embodiment, the digital certificates for system components with digital signing 
capability that are maintained by a participant may be issued by root entity 1 10. 

It should be noted that the system entities may each be provided with additional 
components not shown in FIG. 2, such as the components described in copending U.S. 
25 application serial No. 09/657,605, filed on September 8, 2000, entitled System and Method 
for Providing Certificate Validation and Other Services, U.S. provisional apphcation serial 
No. 60/224,994, filed August 14, 2000, entitled Signing hiterface Requirements, Smart 
Card Compliance Requirements, Warranty Service Functional Requirements, and 
Additional Disclosure, U.S. provisional apphcation serial No. 60/259,796, filed January 4, 
30 2001 , entitled Warranty Manager Application Programming Interface, Warranty Messaging 
Specification, and Warranty Manager Functional Requirements, and copending U.S. 
application serial No. 09/928,998, filed August 14, 2001, entitled System and Method for 
Providing Warranties in Electronic Commerce. 

35 Overview of Authorization Services 
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The authorization services described herein provide a mechanism by which a first 
customer (e.g., customer 108) may confirm the authority of an individual to act on behalf of 
a second customer (e.g., customer 106). For example, authorization services may be used to 
confirm the authority of an individual to sign a particular document or to undertake a 
5 particular financial or performance obligation on behalf of the second customer. More 
specifically, authorization services may be used, to cite just a few specific examples, to 
determine whether a particular employee is authorized to purchase a particular class of 
goods, negotiate a particular type of contract, or undertake to perform in a particular manner 
on behalf of the second customer. 
1 0 It should be recognized that the present system is intended to support a wide variety 

of authorization services that are preferably tailored to the business needs of a particular 
customer or industry. It is therefore impossible to describe completely every possible 
authorization service that may be supported by the present system. Rather, the description 
below provides a generalized framework for defining and implementing authorization 
15 services in a variety of business settings. 

To facilitate understanding of this generalized fi-amework, an exemplary 
embodiment for defining and implementing a particular authorization service is described 
below. The exemplary embodiment comprises a hypothetical subscribing customer, ABC 
Co., that is a customer of an issuing participant, Bank A, and a hypothetical relying 
20 customer XYZ Co., that is a customer of a relying participant, Bank B. ABC Co. employs 
an office manager, known as John Smith, who is authorized to transact on behalf of ABC 
Co. in particular ways, as described in more detail below. 

As noted above, in a preferred embodiment, authorization services are designed and 
implemented in the present system using the following steps. First, a customer and its 
25 participant work together to define a desired authorization service. The authorization- 
service definition preferably includes both a messaging specification for the service and a 
set of rules that govern its use, as described in more detail below. 

Second, the proposed authorization service is presented to a policy management 
authority maintained by root entity 1 10 for approval. The policy management authority 
30 reviews the proposed authorization service for compliance with system operating rules and 
specifications promulgated by root entity 110. 

Third, if the proposed authorization type is approved by the root-entity pohcy 
management authority, the service is implemented within the four-comer model. 

The first and second steps are described in more detail in connection with FIG. 3 
35 below. The third step is described in more detail in connection with FIGs. 4-7 below. 
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Establishing an Authorization Service 

FIG. 3 illustrates a preferred embodiment for establishing a new authorization 
service. As shown in FIG. 3, in step 301, subscribing customer 106 and issuing participant 
1 02 work together to broadly identify the parameters of an authorization service to be 

5 defined. For example, it may be determined that it would be useful to define an 

authorization service for ABC Co. to be used in authorizing purchase of goods or services 
by ABC Co. employees. 

In step 302, subscribing customer 106 and issuing participant 102 work together to 
identify the particular customer and employee information needed to respond appropriately 

10 to such an authorization request. For example, it may be determined that each employee of 
ABC Co. has a title and that the types and amount of goods and services that the employee 
is authorized to obtain on behalf of ABC Co. are a function of that titie. As will be 
recognized, this information will typically vary significantly from authorization service to 
authorization service as a function of the customer, industry, or type of authorization 

1 5 desired. 

In step 303, subscribing customer 106 and issuing participant 102 work together to 
define a credential-record format for storing the categories of information (e.g., title, 
purchasing limit) identified in step 302. This credential-record format is preferably 
customized as appropriate for the particular customer and industry to which the 
20 authorization service pertains. 

In a preferred embodiment, each credential record comprises one or more pairs of 
roles and attributes. A role is a characteristic relevant to the authority of an individual to 
take a particular action. An attribute represents the particular value assigned to a role for a 
given individual. 

25 For example, in the exemplary embodiment, it may be determined that each 

credential record should comprise the following roles: 

(1) Name 

(2) Title 

30 (3) Purchasing Authority 

(4) Purchasing Limit 

An exemplary set of attributes for these roles may be: 
35 (1) John Smith 
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(2) Office Manager 

(3) Office Supplies 

(4) $1,000 



5 In step 304, subscribing customer 1 06 and issuing participant 102 work together to 

identify any additional information that may be necessary to properly respond to 
authorization requests for the authorization type being defined, hi a preferred embodiment, 
this information may include definition information and mapping information. 

Definition information is information used to construe particular attributes assigned 
10 to one or more employees of subscribing customer 106. For example, as noted above, the 
purchasing-authority role for ABC Co.'s office manager may be assigned the attiibute 
"Office Supplies." Definition information is preferably used to define the scope of this 
attribute. For example, definition information may be provided by that defines "Office 
Supplies" as including pens, pencils, paper, adhesive tape, etc., but as excluding (either 

1 5 explicitly or by implication) desks, telephones, photocopy machines, etc. As described 
below. Bank A may refer to this definition information in responding to authorization 
requests concerning the purchasing authority of John Smith. 

Mapping information is information used to interpret an authorization request 
received from an entity that uses different terminology than subscribing customer 106 to 

20 describe the same things. For example, seller XYZ Co. may be located in the United 
Kingdom where the term "sellotape" is used to described what ABC Co. (located, for 
example, in the United States) would refer to as "adhesive tape." Mapping information may 
be used to translate terms in an authorization request into appropriate terminology that 
matches that used by ABC Co. 

25 Additional mapping data may also preferably be maintained by issuing participant 

102 to allow, for example, for currency conversion. Thus, for example, if seller XYZ Co. is 
located in the United Kingdom, it may specify a purchase amount in an authorization 
request in poimds sterling. Bank A may use dynamically-maintained mapping information 
to translate the purchase amount to dollars if, for example, ABC Co. specified its employee 

30 purchasing limits in that currency. 

Li step 305, issuing participant 102 and subscribing customer 106 preferably work 
together to create a messaging specification that defines a format for authorization requests 
and responses to be used in connection with the defined authorization service. As noted, the 
present system is intended to be support a wide variety of authorization services each of 

35 which may be defined as desired by issuing participant 1 02 and subscribing customer 1 06. 
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Accordingly, in a preferred embodiment, the messaging specification may define messages 
in any suitable format such as extensible markup language (XML), hypertext markup 
language (HTML), etc. 

For purposes of the exemplary embodiment described herein, it will be assumed that 
all messages are to be defined in XML format. As such, the messaging specification created 
by issuing participant 102 and subscribing customer 106 preferably comprises a document 
type definition (DTD) that provides the formal description of all valid XML authorization 
request and response messages used in connection with the authorization service being 
defined. Exemplary embodiments for such authorization request and response messages are 
0 described below. 

In a preferred embodiment, an authorization service may be designed to support 
static authorization requests, dynamic authorization requests, or both. 

A dynamic authorization request is a request for approval that an individual is 
authorized to perform a certain act or undertake a particular transaction. For example, a 
dynamic authorization request may specify that a proposed transaction has a value of $500 
and seek to determine whether a particular individual is authorized to transact in that 
amount. A dynamic authorization response preferably returns a Boolean value (e.g., 
"Authorized" or "Not Authorized"). 

A static authorization request is a request for the attribute(s) of one or more roles 
associated with a particular individual. For example, a static request may seek the signing 
limit of a particular corporate officer. A static authorization response returns the particular 
attribute(s) requested. 

In step 306, issuing participant 102 and subscribing customer 106 preferably work 
together in order to define a set of implementation rules that govern use of the authorization 
service being defined. As noted above, the present system is designed to be flexibly 
adaptable to the needs of various businesses in various industries. Accordingly, it is 
impossible to create a complete hst of all such rales that might be proposed by a particular 
subscribing customer 106 and/or issuing participant 102. Illustrative examples of such 
rules, however, may include the following: 

1 . Issuing participant 102 may only respond to a request for authorization 
concerning purchase of office supplies if the request is received fi-om a company that sells 
office supplies. 

2. Issuing participant 102 may only respond to a request for authorization 
concerning purchase of office supplies if the request is received from a company on a list of 
approved suppliers established by subscribing customer 106. 
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3. Issuing participant 102 may only respond to a request for authorization 
concerning purchase of office supplies if the request is received from a particular company, 
e.g., XYZ Co. 

4. Issuing participant 102 may only respond to a request for authorization 

5 concerning purchase of office supphes if the request is received from an individual with a 
title of "sales manager." 

5. Issuing participant 102 may only respond to a request for authorization 
concerning purchase of office supphes if the request is received from a particular individual 
employed by XYZ Co., e.g., Jane Doe. 

1 0 It should be noted that the implementation rules may differ as a function of 

authorization-request type (i.e., a static vs. dynamic authorization request). In particular, a 
subscribing customer 106 may wish to estabhsh more restrictive rules for responding to 
static authorization requests than dynamic information requests. 

It should also be noted that it may often be possible to enforce one or more 
1 5 implementation rules by properly defining the messaging specification for the proposed 
service. For example, a subscribing customer 106 may wish to permit issuing participant 
102 to respond to authorization requests only from relying customers 108 that are in 
possession of a signed purchase order from subscribing customer 106. This implementation 
rale may be enforced by defining an authorization-request message format that includes a 
20 signed-purchase-order field in which relying customer 108 must include a signed purchase 
order from subscribing customer 106. 

hi a preferred embodiment, the implementation rales may also define access confrols 
that limit the ability of relying customers to obtain the messaging formats for the proposed 
service. As will be recognized, the very stracture of an authorization-request or 
25 authorization-response message, and the fields it comprises, may reveal valuable business 
information regarding the stiiicture of a business entity. Such message-format data may 
also provide an attacker with information that might be useful in generating forged 
authorization requests or responses. Accordingly, in a preferred embodiment, the 
implementation rales also define access confrols that limit access to messaging specification 
30 data for the proposed service. For example, access confrols may be used to determine 
whether or not a particular relying customer 108 is entitled to receive the message format 
for a particular type of authorization request, hi a preferred embodiment, these 
implementation rales are typically enforced by root entity 1 10 which is responsible for 
responding to requests for message-format data, as described in more detail below. 

35 
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In step 307, issuing participant 102 presents the proposed authorization service 
including its messaging specification and implementation rules to a policy management 
authority maintained by root entity 1 10. In step 308, the root-entity poHcy management 
authority reviews the proposed service for compliance with system operating rules and 
specifications promulgated by root entity 1 1 0 and determines whether or not to approve the 
proposed service. 

If the root-entity policy management authority does not approve the proposed 
service, it notifies issuing participant 102 of this fact (step 309). The pohcy management 
authority may include with the denial suggested amendments to the messaging specification 
or implementation rules that would conform the authorization service to the operating rules 
and specifications promulgated by root entity 1 10 and permit approval of the proposed 
service. 

If the root-entity policy management authority approves the proposed service, then, 
in step 310, root entity 110 stores the messaging specification and implementation rules for 
the service in central repository 260 and notifies issuing participant of the approval. 

Once approval notification is received, issuing participant 102 stores the approved 
messaging specification and implementation rules in directory 270 and notifies subscribing 
customer 106 of the approval (step 311). hi step 312, subscribing customer 106 supphes 
attribute information to issuing participant 102 to populate credential records for 
subscribing customer 106's employees. For example, as noted above, ABC Co. may have 
an employee whose name is John Smith, whose title is "Office Manager" and who is 
therefore authorized to purchase up to $1000 of office supphes. In the exemplary 
embodiment, ABC Co. would transmit this attribute information (and analogous 
information for its other employees) to Bank A. 

In step 313, issuing participant 102 establishes a credential record for each employee 
of subscribing customer 106 identified to it in step 312. In the exemplary embodiment, for 
example, a credential record for John Smith may appear as follows: 

Name = John Smith 

Title = Office Manager 

Purchasing Authority = Office Supplies 

Purchasing Limit = $1,000 



- 13- 



NY2- 1236929.1 



In step 314, issuing participant 102 stores the credentials records in directory 270. 
In a preferred embodiment, this information may also be stored at subscribing customer 106 
in directory 280. 

5 The authorization service is now ready for use by system customers, as described in 

the following section. 

Authorization Service Process Flow 

A preferred embodiment of a process flow for using an approved authorization 

10 service is now described in connection with FIGs. 4-5. It should be recognized that the 

present system is intended to provide authorization services in a wide variety of situations in 
which one entity might seek authorization of another to transact or undertake some 
obligation. It is therefore impossible to describe completely every possible situation in 
which the authorization services of the present system might be used. The exemplary 

1 5 preferred embodiment described below describes a t3/pical example (purchase of goods by 
one customer from another) in which authorization of an individual might be sought. It will 
be recognized, however, that the authorization services of the present system may be used in 
many other circumstances such as to confirm the authorization of one individual to 
negotiate a particular contract before commencing negotiations (which may be time- 

20 consuming and costly) with that individual. 

For purposes of the present exemplary embodiment, it will be assximed that the 
components shown in FIG. 2 as being associated with the subscribing customer are owned 
and maintained by ABC Co. and assigned for use to John Smith, its office manager. It will 
further be assumed that the components shown in FIG. 2 as being associated with the 

25 relying customer are owned and maintained by XYZ Co. It will further be assumed that the 
components shown in FIG. 2 as being associated with the issuing participant and relying 
participant are owned and maintained by Bank A and Bank B, respectively. 

Beginning with FIG. 4, in step 401, John Smith, the office manager for ABC Co., 
visits the Web site of XYZ Co. using his browser 224. The parties preferably authenticate 

30 themselves to each other over an SSL session with their utility keys. 

Once John Smith agrees to a transaction (e.g., to purchase $200 of adhesive tape), 
Web server 220 communicates data to be digitally signed to browser 224 (e.g., a purchase 
order for the agreed-to transaction) (step 402). In step 403, the data to be signed is 
forwarded to smartcard subsystem 226 which signs the data to create a digitally-signed 

35 document. 
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In step 404, browser 224 receives the digitally-signed document and transmits it to 
Web server 220 or another appropriate location specified by XYZ Co. In a preferred 
embodiment, this signing process may be facihtated by using a signing interface 225 to 
invoke smartcard subsystem 226, as described in U.S. provisional appUcation serial No. 

5 60/224,994, filed September 8, 2000, entitled Signing Interface Requirements, Smart Card 
Compliance Requirements, Warranty Service Fxmctional Requirements, and Additional 
Disclosure and copending U.S. application serial No. 09/929,035, filed August 14, 2001, 
entitled System and Method for Facilitating Signing by Buyer's in Electronic Commerce, 
which are hereby incorporated by reference. 

10 In step 405, XYZ Co. receives the digitally-signed document. In step 406, XYZ Co. 

decides to confirm that John Smith is authorized to sign the purchase order. 

In step 407, XYZ Co. determines whether it has previously obtained the appropriate 
message format for the desired authorization request to be created. As noted, the desired 
authorization request may be a static authorization request or a dynamic authorization 

15 request depending on the type of information that XYZ Co. would like to obtain. If XYZ 
Co. has previously obtained the appropriate message format, processing proceeds to step 
416, described below. 

Otherwise, in step 408, XYZ Co. generates a request for the appropriate 
authorization-request message format, signs the request, and sends the request to Bank B 

20 (message 1 in FIG. 5). In step 409, Bank B transmits the request to root entity 1 10 (message 
2 in Fig. 5). 

In step 410, root entity 110 receives the request and retrieves from central repository 
260 the access-control implementation rules developed by Bank A and ABC Co. for the 
authorization service identified in the request. In step 411, root entity 1 10 applies these 
25 access-control implementation rules to determine whether or not XYZ Co. is authorized to 
receive the requested authorization-request message format. 

If XYZ Co. is not authorized to receive the requested message format, then, in step 
412, root entity 110 generates a rejection message indicating this fact, signs it, and transmits 
it to Bank B (message 3 in Fig. 5). In step 413, Bank B transmits the rejection message to 
30 XYZ Co. (message 4 in Fig. 5), and processing concludes. 

Otherwise, in step 414, root entity 110 retrieves from central repository 260 the 
requested authorization-request message format, creates a signed message that includes the 
requested message format, and transmits the message to Bank B (message 5 in FIG. 5). In 
step 415, Bank B fransmits the message to XYZ Co. (message 6 in FIG. 5). 
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In step 416, XYZ Co. uses the authorization-request message format to generate an 
authorization request for some aspect of the transaction documented by the digitally-signed 
document. 

Assuming for purposes of the present exemplary embodiment that the authorization 
5 service permits a relying customer to make a dynamic request to determine whether an 
employee of ABC Co. is authorized to purchase a particular type and value of goods, an 
exemplary dynamic authorization request message might include the following fields; 

Authorization Request Message Code (indicating that the message is a 
request for authorization and specifying a particular authorization service by number) 
10 • Request Type (indicating whether the request is a static request or a dynamic 

request) 

Request ID (unique identifier generated by relying customer 1 08) 
Relying Customer Name (e.g., XYZ Co.) 
Subscribing Customer Name (e.g., ABC Co.) 
15 • Subscribing Customer Employee (e.g., John Smith) 

• Transaction Type (e.g., purchase, rental, etc.) 

• Transaction Item 
Transaction Amount 

20 An exemplary XML implementation of a dynamic authorization request generated 

for John Smith's authorization to purchase $200 worth of adhesive tape maybe as follows: 

<AuthorizationRequestServiceNol2345> 

<RequestType Type="dynamic"/> 
25 <RequestId Id-"003402 1 ' V> 

<RCNameAndId Id="l 23456" Name="XYZ Co."/> 

<SCNameAndId Id="654321" Name="ABC Co."/> 

<SCEmployeeNameAndId Id="13579" Name-"John Smith"/> 

<TransactionType Type="purchase"/> 
30 <TransactionItem Item="adhesive tape"/> 

<TransactionAmount Currency="USD" Amount="200"/> 
</AuthorizationRequestServiceNo 1 2345> 

Alternatively, assuming for purposes of the present exemplary embodiment that the 
35 authorization service permits a rel3dng customer to make a static request to determine the 
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purchasing authority of an employee of ABC Co., an exemplary static authorization request 
message might include the following fields: 

• Authorization Request Message Code (indicating that the message is a 
request for authorization and specifying a particular authorization service by nimiber) 

5 • Request Type (indicating whether the request is a static request or a dynamic 

request) 

• Request ID (vmique identifier generated by relying customer 1 08) 
Relying Customer Name (e.g., XYZ Co.) 

• Subscribing Customer Name (e.g., ABC Co.) 

10 • Subscribing Customer Employee (e.g., John Smith) 

Requested Attributes (indicating the attributes that are the subject of the 
authorization request) 

An exemplary XML implementation of a static authorization request to determine 
15 the type and value of items that John Smith is authorized to purchase (i.e., his purchasing 
authority and purchasing limit) may be as follows: 

<AuthorizationRequestServiceNol2345> 
<RequestType Type="static"/> 

20 <RequestId Id="00255501"/> 

<RCNameAndId Id="123456" Name="XYZ Co."/> 
<SCNameAndId Id="654321" Name="ABC Co."/> 
<SCEmployeeNameAndId Id="13579" Name="John Smith"/> 
<RequestedAttributes Attributes="Purchasing Authority, Purchasing Limit"/> 

25 </AuthorizationRequestServiceNo 1 2345> 

Continuing with FIG. 4, in step 417, XYZ Co. signs the authorization request 
message and sends it to Bank B (message 7 in FIG. 5). In step 418, Bank B transmits the 
authorization request message to Bank A (message 8 in FIG. 5). 
30 In step 419, Bank A receives the request and checks its repository 270^ to determine 

whether or not it has the appropriate messaging specification data in order to generate a 
response to the authorization request. If Bank A has the appropriate messaging 
specification data, processing proceeds to step 427, described below. 

Otherwise (which may occur, for example, if the authorization service that is the 
35 subject of the request was developed by a different system participant), then, in step 420, 
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Bank A generates a request for the appropriate response message format, signs the request, 
and sends the request to root entity 110 (message 9 in FIG. 5). 

In step 421, root entity 110 receives the request and retrieves from central repository 
260 any applicable access-control implementation rules necessary to process the request. In 
5 step 422, root entity 110 applies these rales to determine whether or not it will release the 
requested authorization-response message format to Bank A. 

If Bank A is not authorized to receive the requested message format, then, in step 
423, root entity 110 generates a rejection message indicating this fact, signs it, and transmits 
it to Bank A (message 10 in FIG. 5). In step 424, Bank A generates a message indicating 
1 0 that it can not process the authorization request, signs it, and transmits it to Bank B 
(message 1 1 in FIG. 5). In step 425, Bank B transmits the message to XYZ Co., and 
processing ends (message 12 in FIG. 5). 

Otherwise, in step 426, root entity 110 retrieves from central repository 260 the 
requested authorization-response message format, creates a signed message that includes the 
15 requested message format, and transmits the message to Bank A (message 13 in FIG. 5). 

In step 427, Bank A retrieves from directory 270ip the appropriate credential record 
for the individual that is the subject of the authorization request (e.g., John Smith). In 
addition. Bank A retrieves from directory 270ip any necessary definition and mapping 
information for processing the request. Bank A uses this information to process the 
20 authorization request from XYZ Co. 

For example, if the authorization request seeks to determine whether John Smith is 
authorized to purchase $200 of adhesive tape. Bank A reviews John Smith's purchasing 
authority attributes (and any necessary related definition or mapping information) and his 
purchasing limit, and determines (on these facts) that John Smith is authorized to conduct 
25 the transaction. 

It should be noted that, in the present exemplary embodiment, it is assumed that the 
purchasing limit attribute assigned to John Smith is a per-fransaction limit. It will be 
recognized that subscribing customer 106 may alternatively or in addition assign to its 
employees time-based (e.g., monthly) or other purchasing limits. If, for example, John 

30 Smith was also assigned a monthly limit. Bank A would preferably frack all purchases made 
by John Smith and maintain a nmning total of those purchases during the last month. Upon 
receipt of an authorization request for a specified transaction amoimt. Bank A would add 
this transaction amount to John Smith's ruiming total for the month, compare the sum to 
John Smith's monthly purchasing limit, and issue a positive authorization only if the sum 

35 did not exceed the monthly purchasing limit. 
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In step 428, Bank A uses the authorization-response message format to generate an 
appropriate response to XYZ Co.'s authorization request. Continuing with the exemplary 
embodiment, a response to the dynamic authorization request described above may include 
the following fields: 

5 • Authorization Response Message Code (indicating that the message is an 

authorization response message and specifying a particular authorization service by number) 

• Request ID 

• Response (Boolean value such as Authorized or Not Authorized) 

10 An exemplary XML implementation of the above response may be as follows: 

<AuthorizationResponseServiceNol2345> 
<RequestId Id="0034201"/> 
<Response>Authorized</Response> 
1 5 </AuthorizationResponseServiceNo 12345> 

A response to the static authorization request described above may include the 
following fields: 

• Authorization Response Message Code (indicating that the message is an 

20 authorization response message and specifying a particular authorization service by nimiber) 

• Request ID 

• Credential Record 

An exemplary XML implementation for such a response message may be: 

25 

<AuthorizationResponseServiceNo 1 2345> 

<RequestId Id="0034201"/> 

<EmployeeName>John Smith</EmployeeName> 

<EmployeeTitle>Office Manager</EmployeeTitle> 
30 <PurchasingAuthority>Office Supplies</PurchasingAuthority> 

<PurchasingLimit Currency="USD">75,000</PurchasingLimit> 
</AuthorizationResponseServiceNo 1 2345> 

In step 429, Bank A signs the authorization response message and sends it to Bank B 
35 (message 14 in FIG. 5). In step 430, Bank B transmits the authorization response message 
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to XYZ Co. (message 15 in FIG. 5). If the authorization response is satisfactory to XYZ 
Co., then, in step 431, XYZ Co. sends a confirmation message for the transaction to John 
Smith at ABC Co. Otherwise, if the authorization response is not satisfactory to XYZ Co., 
then, in step 432, XYZ Co. may send a message to John Smith at ABC Co. disaffirming the 
5 transaction. 

Process Flow for Bundled Authorization Service 
and Certificate Validation or Other System Services 

In a preferred embodiment, an authorization request by a relying customer 108 may 
10 preferably be bundled and processed concurrently with a request for another system service 
such as certificate validation. Preferred embodiments for validating a subscribing customer 
106's certificate are described, for example, in copending U.S. application serial No. 
09/657,605, filed September 8, 2000, entitled System and Method for Certificate Vahdation 
and Other Services, which is hereby incorporated by reference. A summarized version of 
15 that certificate validation process is described below in connection with the bundled 

authorization/certificate validation services. This preferred embodiment is now described in 
coimection with FIGs. 6-7. 

Beginning with FIG. 6, in step 601, subscribing customer 106 visits relying 
customer 108's Web site. The parties preferably authenticate themselves to each other over 
20 an SSL session with their utility keys. 

In step 602, Web server 220 communicates data to be digitally signed to browser 

224 (e.g., a purchase order for an agreed-to transaction). In step 603, the data to be signed is 
forwarded to smartcard subsystem 226 which signs the data to create a digitally-signed 
document. In step 604, browser 224 receives the digitally-signed document and transmits it 

25 to Web server 220 or another appropriate location specified by relying customer 108. In a 
preferred embodiment, this signing process may be facilitated by using a signing interface 

225 to invoke smartcard subsystem 226, as described in U.S. provisional application serial 
No. 60/224,994, filed September 8, 2000, entitied Signing hiterface Requirements, Smart 
Card Compliance Requirements, Warranty Service Functional Requirements, and 

30 Additional Disclosure, which is hereby incorporated by reference. 

In step 605, relying customer 108 receives the digitally-signed document. In step 
606, relying customer 108 generates an authorization request message in accordance with 
steps 407-416, as described above. In step 607, relying customer 108 creates an OCSP 
request for subscribing customer 106's digital certificate. In step 608, relying customer 108 

35 concatenates the two requests and signs the resulting message. In a preferred embodiment. 
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the messaging specification for the authorization service may include a single request that 
seeks both authorization and certificate validation, hi step 609, relying customer 108 
transmits the request(s) to relying participant 104 (message 1 in FIG. 7). 

hi step 610, relying participant 104 identifies the issuing participant that issued the 
5 digital certificate that is the subject of the OCSP request and, in step 611, transmits the 

request to that participant (i.e., issuing participant 102 in the present example) (message 2 in 
FIG. 7). 

In step 612, issuing participant 102 processes the authorization request in 
accordance with steps 419-428 as described above. In step 613, issuing participant creates 

10 an OCSP response for the validation request using its OCSP responder 204ip. In step 614, 
issuing participant 102 concatenates the authorization response message and OCSP 
response and signs the resulting message. In a preferred embodiment, the messaging 
specification for the authorization service may include a single response message for 
responding to a bundled authorization/certificate validation request. 

15 In step 615, issuing participant 102 transmits the response(s) to relying participant 

104 (message 3 in FIG. 7). In step 616, relying participant 104 transmits the response(s) to 
relying customer 108 (message 4 in FIG. 7). In step 617, relying customer 108 reviews the 
response(s). If the authorization and validation responses are satisfactory to relying 
customer 104, then, in step 618, XYZ Co. sends a confirmation message for the transaction 

20 to subscribing customer 106. Otherwise, if one or more of the service responses are not 
satisfactory to relying customer 108, then, in step 619, relying customer 108 may send a 
message to subscribing customer 106 disaffirming the transaction. 

It will be recognized that, in other preferred embodiments, system services other 
than certificate validation may be processed concurrently with the authorization service. 

25 These system service may, for example, include a warranty service. 

It should be noted that, in a preferred embodiment, all inter-entity messages 
transmitted and received by participants 1 02, 1 04, and root entity 110 may be routed 
through an appropriate system component adapted for such processing, such as, for 
example, transaction coordinator 202. 

30 It should be noted that although the preferred embodiments described above speak 

primarily in terms of a transaction conducted by an individual employee of subscribing 
customer 106, the transaction may alternatively be automatically conducted by an 
appropriate server maintained by subscriber customer 106. In that case, relying customer 
108 may, for example, seek an authorization that the subscribing customer will stand behind 

35 a transaction conducted with the server. 
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It should also be recognized that although in the preferred embodiments described 
above subscribing customer 106 and issuing participant 102 work together to design a 
desired authorization service, in an alternative preferred embodiment, issuing participant 
102 (or other entities such as root entity 110) may design in advance one or more 

5 authorization services and seek approval from the policy management authority for them. 
Once approved, these may serve as "off-the-shelf authorization services that may be 
offered to a subscribing customer 106. In particular, it maybe desirable to design and seek 
approval for industry-specific authorization services that an issuing participant expects will 
be popular with its customers. 

10 While the invention has been described in conjunction with specific embodiments, it 

is evident that numerous alternatives, modifications, and variations will be apparent to those 
skilled in the art in light of the foregoing description. 

15 



20 



25 



30 



35 



-22- 



NY2 - 1236929.1 



